Techniques for tracking actual users in web application security systems

ABSTRACT

A method for tracking and identifying an identity of a user accessing a web application. An application normal behavior profile (NBP), wherein said NBP includes a plurality of authentication identifiers of the web application is generated. It is determined using the NBP whether an authentication request submitted by the user was successful. A first actionable data on a successful authentication request is saved. A second actionable data on an unsuccessful authentication request is saved.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority from US provisional application No.60/739,955 filed on Nov. 28, 2005, the contents of which areincorporated herein by reference.

TECHNICAL FIELD

This disclosure relates generally to application level security systems,and more particularly to techniques for tracking hackers by suchsystems.

BACKGROUND OF THE TECHNOLOGY

Currently, a growing number of web applications require a client tocarry out an authentication process prior to being granted access, andprior to being assigned with an application session. In theauthentication process a client declares its identity to the system(“UserId”) together with a proof of that identity (usually passwordbased). The same identity must be presented for each application sessioninvolving a specific client.

In the related art there are at least two techniques used to performauthentication in web applications. The first technique is based on theauthentication protocol semantics described in the Hypertext TransferProtocol Request for Comments (HTTP RFC). In this technique theprotected application responds with a 401 error code wheneverauthentication is required, the client then sends a request with theproper values in the “Authorization” header field and is authenticatedby the application. If the application fails to authenticate the clientit responds again with a 401 error (or a 403 error).

The second technique, also known as “form authentication”, is morecommonly used and relies on HTML forms in which the client types theUserID and password. The form is submitted to a specific module in theweb application (using a HTTP request). The module evaluates theclient's credentials and responds accordingly. In both techniques, oncean authentication is successful, the client is not required to resendthe credentials throughout the rest of the application session.Specifically, the server internally associates the session identifiersent to the user (in the form of a cookie) with the identification tokenrepresenting that user.

Web application security systems are required to be able to correlatemultiple requests that constitute a single attack. Traditionaltechniques, taken from network security domain, rely on the source IPaddress of the request. This type of correlation is inadequate in thedomain of web applications because of the prevailing use of networkaddress translation (NAT), on one hand, and the ability of an attackerto switch IP addresses quickly during an attack, on the other hand.Attacker can switch IP addresses either by using proxies, dial-upconnection, or any other techniques. More advanced protection techniquesrely on the notion of application session as maintained by the webserver using some mechanism for keeping session for HTTP requests (e.g.cookies). While these are more adequate techniques, they fail to providea robust solution since session creation is controlled by the clientrather than the server. For example, a client may refuse to send anexisting cookie and by that invoke the generation of a new session witha new cookie by the server. Therefore, it would be advantageous toprovide a more robust correlation mechanism for web applicationprotection.

SUMMARY

To realize some of the advantages noted above, there is provided amethod for tracking and identifying an identity of a user accessing aweb application. An application normal behavior profile (NBP), whereinsaid NBP includes a plurality of authentication identifiers of the webapplication is generated. It is determined using the NBP whether anauthentication request submitted by the user was successful. A firstactionable data on a successful authentication request is saved. Asecond actionable data on an unsuccessful authentication request issaved.

In another specific enhancement a corresponding user identification isattached to each subsequent authentication request submitted by theuser.

In another specific enhancement the plurality of authenticationidentifiers comprise at least: an authentication form, a login patternof the successful authentication request, a login pattern of theunsuccessful authentication request.

More specifically, the authentication form is a hypertext markuplanguage (HTML) form.

More specifically, the login pattern includes at least one loginindication and a value of said at least one login indication.

Even more specifically, the login indication comprises at least one of:a response code, existence of redirect directives, a target URL ofredirect directives, and existence of the authentication form.

More specifically, the NBP is generated to include the plurality ofauthentication identifiers by a process including identifying at leastone authentication form in a reply to the submitted authenticationrequest and identifying at least one login pattern in the reply.

More specifically, identifying the authentication forms further includesanalyzing said at least one authentication form in the reply. A searchis conducted for at least one identifier parameter in the at least oneauthentication form. A number of occurrences of additionalauthentication forms that has the at least one identifier parameterduring a predefined time interval is counted. The at least oneauthentication form is added to the NBP if the number of occurrencesexceeds a predefined threshold.

More specifically, the identifier parameter comprises at least one of:an input field of type password, an input field of type text.

More identifying the at least one login pattern further includes markingeach combination of login indications found in the reply. A number ofobservations of each combination during a predefined time interval iscounted. A combination of login indications is determined as the loginpattern of a successful authentication request if a corresponding numberof observations exceeds a predefined threshold. A combination of loginindications is determined as the login pattern of an unsuccessfulauthentication request if a corresponding number of observations isbelow a predefined threshold.

More specifically, determining whether the authentication request wassuccessful further includes extracting values of the login indicationsfrom a response associated with the authentication request. It ischecked if the extracted values of the login indications exist in theNBP. It is determined that the authentication request was successful ifthe extracted values exist in the NBP.

In another specific enhancement the actionable data on the successfulauthentication request comprises at least one of: a user identification,a session identification, a user name, an internet protocol address,actions preformed by the user.

More specifically, the actionable data on the successful authenticationrequest is utilized to track users across many sessions and days.

In another specific enhancement the first actionable data on theunsuccessful authentication request comprises at least one of: a sessionidentification, a user identification, an internet protocol addressassociated with the user.

More specifically, second actionable data on the unsuccessfulauthentication request is utilized for detecting brute force attacks.

Another aspect of the disclosed teachings is a computer program productincluding a computer readable medium having instructions for enabling acomputer to perform the above discussed methods.

Still another aspect of the disclosed teachings is security systemhaving user awareness capabilities for tracking and identifying theidentity of users accessing a web application, the system comprises asecure server coupled to a secure gateway and operable to generate anapplication normal behavior profile (NBP) that includes at least aplurality of authentication identifiers of the web application. At leastone secure gateway is installed in a line of traffic between a clientand a web server and operable to determine using the NBP whether anauthentication request from the client was successful.

In another specific enhancement the authentication request is submittedby a user.

More specifically, the secure gateway is further operable to save firstactionable data on a successful authentication request and furtheroperable to save second actionable data on an unsuccessfulauthentication request and labeling each authentication request with anidentity of the actual user.

In another specific enhancement, the system is further operable toidentify authentication forms in replies to submitted authenticationrequests and identify login patterns in replies to the submittedauthentication requests.

More specifically, to determine whether the authentication request wassuccessful, the system is operable to extract values of at least loginindications from a response associated with the authentication request,and further operable to check if the extracted values of the loginindications exist in the NBP; and further operable to determine that theauthentication request was successful if the extracted values exist inthe NBP.

More specifically, the first actionable data on the successfulauthentication request comprises at least one of: a user identification,a session identification, a user name, an internet protocol address,actions preformed by the user.

More specifically, the first actionable data actionable data on thesuccessful authentication request is utilized to track users across manysessions and days.

More specifically, the second actionable data on the unsuccessfulauthentication request comprises at least one of: a sessionidentification, a user identification, an internet protocol addressassociated with the user.

More specifically, the second actionable data on the unsuccessfulauthentication request is utilized for detecting brute force attacks.

BRIEF DESCRIPTION OF THE DRAWINGS

The above objectives and advantages of the disclosed teachings willbecome more apparent by describing in detail preferred embodimentsthereof with reference to the attached drawings in which:

FIG. 1 is a diagram of an application level security system.

FIG. 2 is a flowchart describing the method for detecting authenticationoperations and generating actionable data in accordance with anexemplary embodiment of the disclosed teachings.

FIG. 3 is a flowchart describing the process for identifyingauthentication forms in accordance with an exemplary embodiment of thedisclosed teachings.

FIG. 4 is a flowchart describing the process for identifying successfullogins in accordance with an exemplary embodiment of the disclosedteachings.

DETAILED DESCRIPTION

Techniques for automatically identifying the client identity as embodiedby the UserID of each application session are disclosed. Specifically,techniques for identifying the specific module in a web application thatvalidates credentials and for assessing whether a specificauthentication request was successful or not are disclosed. Alsodisclosed is a web application security system having user awarenesscapabilities.

Using the disclosed techniques in a web application security system thatis capable of tracking application sessions, each and every clientrequest can be labeled with the identity of the actual user. Thus,robust correlation mechanism based on the actual client that generatedthe request is achieved. A web application security system can use theuser awareness capabilities for a more accurate detection of attacks. Italso has a better attack thwarting mechanism. For example, it can blockall session of a user rather than a single session. The system providesa better and more meaningful attack reporting. Furthermore, an operatorcan take actions against an actual user. Better auditing of applicationaccess can be provided. For example, an operator can monitor anybehavior of specific clients. Furthermore, by using the techniquesdisclosed, web applications can be protected against specific attacksthat are aimed at the authentication process such as brute forceguessing.

FIG. 1 shows a non-limiting and exemplary diagram of an applicationlevel security system 100 that carries out the techniques disclosed.Security system 100 includes a plurality of secure gateways 130connected to a secure server 110. Secure gateways 130 may be connectedto server 110 through out-of-band network (not shown) for transferringtraffic over a dedicated and secure network that is completely separatedfrom the production traffic. A secure gateway 130 is placed on eachnetwork segment that includes servers 160 (e.g., Web or databaseservers) to be protected. Access to one or more Web applications thatreside on one of servers 160 is permitted only after a user successfullylogs-on to server 160. For this purpose, server 160 provides anauthentication service as described in greater detail herein.

Security system 100 is a non-intrusive system, and thus each of securegateways 130 is configured to operate in the line of traffic, i.e.,traffic passing directly through the secure gateways 130 to protectedserver 160. Specifically, each of the secure gateways 130 gathers, andreconstructs application requests sent to protected server 160. A securegateway 130 further matches the reconstructed request against apredetermined application normal behavior profile (NBP). Applicationrequests are sent by client 190.

A NBP is generated by the secure server 110 and includes a plurality ofapplication attributes such as uniform resource locators (URLs),cookies, users' information, IP addresses, query statements, and manyothers. These attributes determine the normal behavior of the protectedapplication. If one or more of the application requests do not match theNBP an alert providing an indication of a potential attack is produced.In accordance with the exemplary implementation of the disclosedteachings, a NBP includes at least a list of authentication (or login)forms, i.e., web pages that encapsulate an authentication service. Foreach such form, a NBP further includes a list of login indications andtheir values. Secure gateways 130 monitor incoming requests in order todetect candidate authentication forms. These forms are forwarded tosecure server 110 which determines if they should be included in theNBP. If so, secure server 110 updates the NBP of the protectedapplication. Additionally, secure gateways 130 monitor responses thatresult from login requests. In these responses, each secure gateway 130looks for values of the login indications and passes them to secureserver 110, which in turn determines if these values indicate asuccessful login. If so, the NBP is updated and uploaded to securegateways 130.

FIG. 2 shows a non-limiting and exemplary flowchart 200 describing thetechnique for detecting authentication operations and generatingactionable data from such operations, in accordance with certain aspectsof the disclosed teachings. At S210, a process for identifyingauthentication forms in the protected web application is applied.

FIG. 3 shows an example of the execution of S210 in greater detail. AtS310, the server replies are monitored and inspected for HTML forms. AnHTML form is identified by the FORM tag and includes one or more INPUTtags. The FORM tag contains an ACTION attribute, i.e., a URL thatspecifies the target page, which handles the input from a user. Thispage may be the embodiment of the authentication service. At S320, ineach of the forms discovered at S310, the process looks for theidentifier parameters. As a non-limiting example such parameter may be:a single input field of type “password”. This identifier parameter canbe further corroborated with heuristics regarding the “NAME” attributeof this field such as “passwd”, “pass”, “RegPass”, “pass_*”, “pswd”,“UserPassword”, “user_password”, “login_password”, “pc”, “user_pin”,“pin”. As another example, an identifier parameter may be two inputfields of type “text”. This indication can be further corroborated withheuristics regarding the “NAME” attribute of the fields such as “login”,“id”, “user”, “user_id”, “UserId”, “user_name”, “UserName”, “LoginName”,“email”, “login_email”, “nick_*”.

At S330, it is checked if a form includes the identifier parameterstested for in S320, and if so it is considered a candidate and executioncontinues with S340; otherwise, execution terminates. At S340, the valueof the “ACTION” attribute together with the “NAME” attribute of thefirst text field are sent to the server 110. At S350, secure server 110counts the number of occurrences of each candidate form during apredefined time interval (e.g., 24 hours). At S360, the number ofoccurrences is compared to a predefined threshold. If the count exceedsthe threshold, the candidate form is actually an authentication form andadded, at S370, to the NBP of the protected application; otherwise,execution terminates.

Referring back to FIG. 2 where at S220, a process for learning thepattern of successful and failed login operations is applied. Secureserver 110 dose not hold the authentication data of users. Therefore,when a user authenticates, secure server 110 cannot determine whether itis a successful or failed login by using the UserID and password enteredby the user, and thus such a decision is made based on the response sentby server 160.

FIG. 4 shows an example of the execution of S220 in greater detail. AtS410, a response that a server 160 sends back to client 190 is received.Such a response is a reply to a login request. At S420, in each suchresponse the process looks for one or more login indications. Theselogin indications include at least a response code, existence ofredirect directives, a target URL of redirect directives, and theexistence of an authentication form (as described above) in the HTMLpart of the response. At S425, the indications are sent to secure server110. At S430, each combination of indications is given a unique markingand a counter is maintained for the number of observations of eachcombination. At S440 it is checked whether the number of observationsexceeds a given threshold (e.g. 100 login attempts). If so, executioncontinues at S450, otherwise execution ends. At S450, secure server 110checks for the combination of indications (or group of suchcombinations) whose proportion within the total number of observationexceeds a given threshold (e.g. 80%). This combination of indications isthen declared to indicate a successful authentication and is added, atS460, to the NBP. It should be noted that the technique described inFIG. 4 teaches how to detect responses that represent successful logins.However, a person skilled in the art can easily adapt this process toidentify responses representing failed logins.

Referring back to FIG. 2 where at step S230 the updated NBP, thatincludes the learnt authentication forms and successful loginindications, is uploaded to secure gateways 130, and subsequently,system 100 switches to a protection mode that begins with step S240.

At S240, a secure gateway 130 receives a login request and waits for therespective response from a server 160 that handles this request. AtS250, the secure gateway 130 extracts login indications from theresponse and, at S260, compares them to the values saved in the NBP. Ifa match exists, then it is considered as a successful login andexecution continues with S270; otherwise, the login has failed andexecution continues at S280. At S270, parameters such as the UserID,SessionID, and the actions that the user preformed, are saved in asuccess list. This list may further include an IP address, a user name,and other related information. The actionable data in the success listcan be used to track a user across many sessions and days and takeactions against specific users. For example, a security officer canprovide the authorities with incriminating data, stored in the successlist, of users who committed unauthorized actions in the protectedapplication. At S280, the session ID, UserID and preferably an IPaddress associated with a user that failed to login are saved in afailure list. At S290, the user identity (i.e., UserID and username) isattached to subsequent requests that belong to the same session. In anexemplary embodiment, static based authorization rules may be applied ona request. For example, an authorization rule may define that a specificURL can be accessed only by designated users.

In another exemplary embodiment, the information kept in the failurelist can be used for the detection of brute force attacks. Such attacksare committed by trying large number of password combinations until acombination is found that enables the penetration into the application.In order to detect such attacks, system 100, using data in the failurelist, counts the number of failed logins from the same UserID over apredetermined short period of time. If and when the count exceeds apredefined threshold an alert is generated.

Other modifications and variations to the invention will be apparent tothose skilled in the art from the foregoing disclosure and teachings.Thus, while only certain embodiments of the invention have beenspecifically described herein, it will be apparent that numerousmodifications may be made thereto without departing from the spirit andscope of the invention.

1. A method for tracking and identifying an identity of a user accessinga web application, the method comprising: generating an applicationnormal behavior profile (NBP), wherein said NBP includes a plurality ofauthentication identifiers of the web application; determining using theNBP whether an authentication request submitted by the user wassuccessful; saving a first actionable data on a successfulauthentication request; and saving a second actionable data on anunsuccessful authentication request.
 2. The method of claim 1, furthercomprising: attaching a corresponding user identification to eachsubsequent authentication request submitted by the user.
 3. The methodof claim 1, wherein the plurality of authentication identifiers compriseat least: an authentication form, a login pattern of the successfulauthentication request, a login pattern of the unsuccessfulauthentication request.
 4. The method of claim 3, wherein theauthentication form is a hypertext markup language (HTML) form.
 5. Themethod of claim 3, wherein the login pattern includes at least one loginindication and a value of said at least one login indication.
 6. Themethod of claim 5, wherein the login indication comprises at least oneof: a response code, existence of redirect directives, a target URL ofredirect directives, and existence of the authentication form.
 7. Themethod of claim 3, wherein generating the NBP to include the pluralityof authentication identifiers further includes: identifying at least oneauthentication form in a reply to the submitted authentication requestand identifying at least one login pattern in the reply.
 8. The methodof claim 7, wherein identifying the authentication forms furtherincludes: analyzing said at least one authentication form in the reply;searching for at least one identifier parameter in the at least oneauthentication form; counting a number of occurrences of additionalauthentication forms that has the at least one identifier parameterduring a predefined time interval; and adding the at least oneauthentication form to the NBP if the number of occurrences exceeds apredefined threshold.
 9. The method of claim 8, wherein the identifierparameter comprises at least one of: an input field of type password, aninput field of type text.
 10. The method of claim 7, wherein identifyingthe at least one login pattern further includes: marking eachcombination of login indications found in the reply; counting a numberof observations of each combination during a predefined time interval;determining a combination of login indications as the login pattern of asuccessful authentication request if a corresponding number ofobservations exceeds a predefined threshold; and determining acombination of login indications as the login pattern of an unsuccessfulauthentication request if a corresponding number of observations isbelow a predefined threshold.
 11. The method of claim 5, whereindetermining whether the authentication request was successful furtherincludes: extracting values of the login indications from a responseassociated with the authentication request; checking if the extractedvalues of the login indications exist in the NBP; and determining thatthe authentication request was successful if the extracted values existin the NBP.
 12. The method of claim 1, wherein the actionable data onthe successful authentication request comprises at least one of: a useridentification, a session identification, a user name, an internetprotocol address, actions preformed by the user.
 13. The method of claim12, wherein the actionable data on the successful authentication requestis utilized to track users across many sessions and days.
 14. The methodof claim 1, wherein the first actionable data on the unsuccessfulauthentication request comprises at least one of: a sessionidentification, a user identification, an internet protocol addressassociated with the user.
 15. The method of claim 14, wherein secondactionable data on the unsuccessful authentication request is utilizedfor detecting brute force attacks.
 16. A computer program productincluding a computer-readable medium comprising instructions, saidinstructions when executed on a computer enables the computer toimplement a method to track and identify identity of a user accessing aweb application, the method comprising: generating an application normalbehavior profile (NBP), wherein said NBP includes a plurality ofauthentication identifiers of the web application; determining using theNBP whether an authentication request submitted by the user wassuccessful; saving a first actionable data on a successfulauthentication request; and saving a second actionable data on anunsuccessful authentication request.
 17. The computer program product ofclaim 16, wherein the implemented method further comprises: attaching acorresponding user identification to each subsequent authenticationrequest submitted by the user.
 18. The computer program product of claim16, wherein the plurality of authentication identifiers comprise atleast: an authentication form, a login pattern of the successfulauthentication request, a login pattern of the unsuccessfulauthentication request.
 19. The computer program product of claim 18,wherein the authentication form is a hypertext markup language (HTML)form.
 20. The computer program product of claim 18, wherein the loginpattern includes at least one login indication and a value of said atleast one login indication.
 21. The computer program product of claim20, wherein the login indication comprises at least one of: a responsecode, existence of redirect directives, a target URL of redirectdirectives, and existence of the authentication form.
 22. The computerprogram product of claim 18, wherein generating the NBP to include theplurality of authentication identifiers further includes: identifying atleast one authentication form in a reply to the submitted authenticationrequest and identifying at least one login pattern in the reply.
 23. Thecomputer program product claim 22, wherein identifying theauthentication forms further includes: analyzing said at least oneauthentication form in the reply; searching for at least one identifierparameter in the at least one authentication form; counting a number ofoccurrences of additional authentication forms that has the at least oneidentifier parameter during a predefined time interval; and adding theat least one authentication form to the NBP if the number of occurrencesexceeds a predefined threshold.
 24. The computer program product ofclaim 23, wherein the identifier parameter comprises at least one of: aninput field of type password, an input field of type text.
 25. Thecomputer program product of claim 22, wherein identifying the at leastone login pattern further includes: marking each combination of loginindications found in the reply; counting a number of observations ofeach combination during a predefined time interval; determining acombination of login indications as the login pattern of a successfulauthentication request if a corresponding number of observations exceedsa predefined threshold; and determining a combination of loginindications as the login pattern of an unsuccessful authenticationrequest if a corresponding number of observations is below a predefinedthreshold.
 26. The computer program product of claim 20, whereindetermining whether the authentication request was successful furtherincludes: extracting values of the login indications from a responseassociated with the authentication request; checking if the extractedvalues of the login indications exist in the NBP; and determining thatthe authentication request was successful if the extracted values existin the NBP.
 27. The computer program product of claim 16, wherein theactionable data on the successful authentication request comprises atleast one of: a user identification, a session identification, a username, an internet protocol address, actions preformed by the user. 28.The computer program product of claim 27, wherein the actionable data onthe successful authentication request is utilized to track users acrossmany sessions and days.
 29. The computer program product of claim 16,wherein the first actionable data on the unsuccessful authenticationrequest comprises at least one of: a session identification, a useridentification, an IP address associated with the user.
 30. The computerprogram product of claim 29, wherein the second actionable data on theunsuccessful authentication request is utilized for detecting bruteforce attacks.
 31. A security system having user awareness capabilitiesfor tracking and identifying the identity of users accessing a webapplication, the system comprises: a secure server coupled to a securegateway and operable to generate an application normal behavior profile(NBP) that includes at least a plurality of authentication identifiersof the web application; and at least one secure gateway installed in aline of traffic between a client and a web server and operable todetermine using the NBP whether an authentication request from theclient was successful.
 32. The security system of claim 31, wherein theauthentication request is submitted by a user.
 33. The security systemof claim 32, wherein secure gateway is further operable to save firstactionable data on a successful authentication request and furtheroperable to save second actionable data on an unsuccessfulauthentication request and labeling each authentication request with anidentity of the actual user.
 34. The security system of claim 31,wherein the system is further operable to identify authentication formsin replies to submitted authentication requests and identify loginpatterns in replies to the submitted authentication requests.
 35. Thesecurity system of claim 32, wherein to determine whether theauthentication request was successful, the system is operable to extractvalues of at least login indications from a response associated with theauthentication request, and further operable to check if the extractedvalues of the login indications exist in the NBP; and further operableto determine that the authentication request was successful if theextracted values exist in the NBP.
 36. The security system of claim 33,wherein the first actionable data on the successful authenticationrequest comprises at least one of: a user identification, a sessionidentification, a user name, an internet protocol address, actionspreformed by the user.
 37. The security system of claim 36, wherein thefirst actionable data actionable data on the successful authenticationrequest is utilized to track users across many sessions and days. 38.The security system of claim 33, wherein the second actionable data onthe unsuccessful authentication request comprises at least one of: asession identification, a user identification, an internet protocoladdress associated with the user.
 39. The security system of claim 38,wherein the second actionable data on the unsuccessful authenticationrequest is utilized for detecting brute force attacks.